1. Field of the Invention
The present invention relates generally to scalable communication within a distributed computer system and relates, more particularly, to management software in a client-server network environment controlling communication between either the client and/or each node of a group of one or more nodes of the network on the one hand, and all remaining nodes of the network including those in the group on the other hand, by way of one or more dynamically-configured communication trees.
2. Description of Prior Art
The computer industry has been growing very rapidly. It includes various sub-industry segments such as computer hardware, computer software, etc. In the computer software arena, various well-defined categories of software have been developed including operating system software, applications software, utility software, management software, etc. The latter category is also known as “distributed management software” if distributed over components of a computer system or over nodes within a computer network such as a client-server network. Such software functions to manage or aid in management of computer system or computer network operation. For example, if storage system components are deployed in a computer system or in a client-server network environment running certain distributed management software, that software can be useful in obtaining and analyzing information about operating states of these storage systems. Operation of such software can result in detecting failed or deteriorated components, thereby assisting in overall management of the computer system or client-server network. This is one environment in which embodiments of the present invention are useful.
If this client-server network environment is running object-oriented software, then, typically, many objects reside in each of these components or nodes and information from each of these objects may be necessary to satisfy certain information requests in pursuit of executing certain management software functions. An object, also sometimes referred to as a node, in computer software terms, is a dedicated area of memory which can be thought of as an impervious container holding both data and instructions within itself, both defining itself and its relationships to other objects in the computer system or network. An object or node can send and receive messages to and from other objects, respond and react to such messages (e.g. commands) but shall normally be impervious to internal scrutiny. For example, in a storage processor (a kind of computer) each object may describe or relate to a specific tangible detail in the processor (e.g. a fan, power switch, cache memory, power supply, disk drive interface, etc.), where these tangible objects in the storage processor can send messages to each other and to other objects outside the processor. The relationship between these specific objects in the storage processor is usually visualized or characterized as a “tree” of objects or nodes. In a tree, each such object hangs off a preceding object as if in a parent-child or inheritance relationship, with many children hanging from a parent not being an atypical configuration. A child node which, in turn, has no children hanging from it is sometimes called a “leaf” node or object since it may have some resemblance to a “leaf” dangling from a tree. In addition to these tangible kinds of objects, logical units (LUNs) are other nodes or objects that can be contained within the tree. Object trees, typically, are permanent in the sense that once built they persist in memory and remain as configured.
Typically, in a client-server network environment in which object-oriented software is employed, there can be many components or network nodes or objects comprising the network. Referring to FIG. 1, there is shown a prior art view of a user interface (UI) or client or management workstation 101 operatively coupled by way of bidirectional busses to a series of components or network nodes 102. In this Fig. there are only six such network nodes shown, but they are associated by dots to imply that the number can be much greater. In certain cases, the number of such network nodes or objects can become very large or scalable and exceed one-thousand and possibly exceed ten-thousand. In the configuration shown all nodes are directly connected to client 101. For large numbers of nodes, this typically results in a severe drain upon resources of client 101 as it must deal with each node or object or component 102 separately. This drain, in turn, results in client 101 not being able to process other, and possibly more important, information of which it would otherwise be capable.
One prior art improvement to this severe drain of client resources problem is shown in FIG. 2, wherein a large server (a computer system or portion thereof dedicated to serve in a particular capacity) is introduced. In this configuration, client 201 is communicatively coupled by a bidirectional bus only to server 203. Server 203 is communicatively or operatively coupled by bidirectional busses to components or nodes or objects 202. (Again, more than six such nodes or objects are implied by the dotted association between the nodes, which again can number in the thousands, tens of thousands, or more.) A marginal improvement is achieved in this configuration because the communication load with nodes 202 is shifted from client 201 to server 203. This does free-up client 201 to an extent, but this server approach does have certain drawbacks. One serious drawback is that there is additional cost associated with server 203. Cost of server 203 relative to cost of each of nodes 202 can be disproportionately large, possibly by orders of magnitude, particularly where each of nodes 202 might be a small or medium-capacity storage system and where the server is very large. In this scenario, a user of these storage systems would normally not be inclined to spend huge amounts of money for a server to manage relatively inexpensive storage systems. In addition to costs of purchase, maintenance of such a server can be very costly because there is complexity associated with server 203 and the server itself has to be managed. This requires additional software which typically is expensive, and results in additional effort and responsibility for the user. Finally, this approach does not scale well, (this approach is not scalable or does not allow large numbers of nodes or objects to be managed) because single server 203 itself becomes a bottleneck when the number of nodes reaches a critical limit for the particular server being employed. Accordingly, a better solution than this intermediary large server solution is needed.
Another prior art approach sometimes used is called “broadcast”. In this approach, in each broadcast the client sends out a singular communique to any and all nodes connected to the network that may, or should, be able to receive it. This is not sending a particular request to one particular node. This approach, which may be useful in certain networking environment applications employing routers, switches, bridges, gateways, etc., has limited value in the instant context of client-server distributed management software. There is no guaranteed delivery; if there is no response there is no information explaining the non-response. If the client simply “shouts-out”, and all nodes and components who can receive and respond do so, then that begs the question: did all components and nodes respond? The system cannot determine if a non-response means that a particular node is inoperative or non-existent. Thus, there is insufficient precision under a broadcast approach which makes that approach unacceptable for many applications. Broadcast techniques will also not work in all network environments; the networks in which they will work must be pre-arranged to allow broadcast at a non-trivial expense. Furthermore, use of broadcast floods the entire network with continuous communiques, which overwhelms the environment and is simply not feasible or scalable for very large configurations.
Accordingly, a need exists for an inexpensive, accurate, robust, reliable and flexible technique for a client, or any node in a client-server network environment, to communicate with all other nodes—to send commands and receive responses—with virtually no practical upper limit to number of nodes that may be deployed throughout the network and in a manner that avoids prior art shortcomings. Embodiments of the present invention, including those disclosed herein, provide a welcome solution to these problems and shortcomings of the prior art.